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"A MECHANISM TO ALLOW AUTHENTICATION OF TERMINATED SIP 

CALLS' 1 

5 Field of the invention 

The present invention relates to a method and a network 
system for performing authentication of terminated calls, 
in particular of terminated SIP (Session Initiation 
10 Protocol) calls* 

BACKGROUND OF THE INVENTION 

15 In general, subscriber to corresponding services are 
authenticated. 

There are many different authentication methods- In the 
following, a Challenge Response based authentication 
20 method is described in short as an example . 

The network node which actually performs the 
authentication requests a parameter set consisting of a 
random number RAND (usually, 128 bit) and a scheduled 

25 result (RESP) from an Authentication Center (AuC) and 
sends the RAND to the mobile node. In turn, the mobile 
node (MS , mobile station) has to calculate a result 
RESP_CALC from the number RAND. The calculation is 
performed in the mobile node by using a secret algorithm, 

30 The user identity, the challenge and a key shared between 
the user and the authenticator are taken as inputs to an 
authentication algorithm, thus resulting in the expected 
output. The shared key must be kept private and only the 
user and the authenticator should know it; but the 

35 authentication algorithm can be publicly known. 
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The result RESP_CALC is transmitted to the network node 
performing a verification of the authentication. It 
checks whether the scheduled result RESP is equal to the 
5 calculated result RESP_CALC. If both results are equal, 
the authentication is successful, otherwise it fails. 

In mobile applications, and in particular in cellular 
networks, the serving network (i.e. the network providing 
10 services to the mobile nodes) can typically authenticate 
the mobile node in three situations: when the mobile node 
registers with the network, when the mobile node 
establishes communications, and when incoming 
communications are terminated to the mobile node. 

15 

The invention applies to networks, such as, e.g., Voice 
over IP (VoIP) networks, where the SIP protocol is 
adopted as control protocol to setup multimedia 
communications, for example. In particular, the invention 
20 applies to the case of mobile VoIP networks where calls 
need to be delivered to mobile nodes - 

The SIP protocol provides a mechanism to allow 
authentication of a SIP terminal when the terminal 

25 registers to a SIP server and when the terminal 

establishes a SIP call. Currently, SIP does not foresee 
any mechanism to support authentication of SIP calls 
delivered to the mobile node. That is, SIP , as currently 
defined, does not allow authentication of terminated 

30 calls. 

Thus, in order to apply SIP to VoIP mobile network, 
authentication of mobile terminated calls need to be 
supported . 



35 
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SUMMARY OF THE INVENTION 

Therefore, che object underlying the invention resides in 
5 providing a mechanism which allows an authentication of a 
subscriber in a mobile terminated call* 

This object is solved by a method of performing 
authentication of a subscriber during a subscriber 
10 equipment terminated call, comprising the steps of 
sending a session invitation message to the 
subscriber equipment, the session invitation message 
including authentication information, and 

performing an authentication procedure in the 
15 subscriber equipment by using the authentication 
information. 

Alternatively, the above object is solved by a network 
control element, wherein, during a subscriber equipment 
20 terminated call, the network control element is adapted 
to send a session invitation message to the 
subscriber equipment, the session invitation message 
including authentication information - 

25 Furthermore, the above object is solved by a subscriber 
equipment which is adapted to be connected to a network, 
and, during a subscriber equipment terminated call, 

to receive a session invitation message from the 
network, the session invitation message including 
30 authentication information, and 

to perform an authentication procedure by using the 
authentication information - 



Thus, according to the invention, information necessary 
35 for performing an authentication procedure is included in 
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a session invitation message which is sent during a 
subscriber equipment terminate^ call to the subscriber 
equipment . 

5 Therefore, no additional messages have to be created or 
transmitted, thus reducing the signaling load on the 
network. 1 

■ * 
Moreover, the above mechanism 'can easily be implemented, 
10 since only new parameters have to be included in fields 
of existing control protocol messages. That is, the 
invention provides a simple mechanism and can easily be 
implemented. j 

15 A response message as a response to the session 

invitation message may be sent from the subscriber 
equipment to the network, the : response message including 
a result of the authentication procedure, 

20 Thus, the calculated result of the authentication 
procedure is included in a response message to the 
session invitation, That is, also for transmitting the 
result of the authentication, ' no additional message is 
required, which also reduces the signaling load on the 

2 5 network. 

The authentication procedure result may be verified in a 
network control element- In case of a positive 
authentication result, the response message of the 
30 subscriber equipment may be forwarded to the originating 
entity without the result of the authentication 
procedure . 

Thus, the establishment of the call between the 
35 originating entity (i.e., caller) and the subscriber 
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entity (i.e., callee) can easily be completed by 
forwarding the response message without the parameter 
indicating the authentication procedure result calculated 
by the subscriber equipment. 

In case of a negative verification, a failure message may 
be forwarded to the originating entity. Hence, in case 
the subscriber equipment is not authenticated, the 
originating entity (i.e., the caller) is notified about 
this . 

In the network, the SIP (Session Initiation Protocol) 
protocol may be adopted as a control protocol. For 
example, the session invitation message may be a SIP 
15 INVITE request including an authentication header field. 
The response message may be a SIP response message 
including an authorization header field* 

The verification may be performed in a network control 
20 element serving the originating entity. 

Alternatively, the verification may be performed in 
another network control element than that network control 
element serving the originating entity. In this case, a 
25 scheduled result for the authentication may be forwarded 
to the other network control element by including the 
scheduled result into the session invitation message. 
Moreover, the other network control element may extract 
the scheduled result from the session invitation message 
30 in the other network control element and forward the 

session invitation message without the scheduled result 
to the subscriber equipment. 



In this way, also the part authentication information 
35 which is necessary to verify the authentication can be 
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conveyed in the session invitation message (e.g., SIP 
INVITE request) . That is, the signaling load on the 
network is further reduced. 

5 The network control element may be adapted to determine 
whether it has to perform the verification of the 
authentication or not. Thus, in response to this 
determination, the network control element may perform 
the above steps or not . 

10 

Optionally, a response message may be sent as a response 
to the session invitation message from the subscriber 
equipment to the network, the response message including 
a result of the authentication procedure and network 
15 authentication information which is used by the 

subscriber equipment to perform an authentication of the 
network. That is, the user, i.e., the callee has the 
possibility to perform an authentication of the network. 

20 During such a network authentication, the network may 

determine a network authentication result in response to 
the network authentication information by the network, 
and send the network authentication result to the 
subscriber equipment, such that the subscriber equipment 

25 may verify the network authentication result. 

Furthermore, the authentication procedure performing step 
and the verification step may be repeated a predetermined 
number of times, wherein different authentication 
30 information may be used. That is, a mutiple round trips 
authentication scheme may be used. 

The authentication data to be sent to the subscriber 
equipment may comprise a invitation to the user to type a 
35 password. Hence, the authentication result may comprise 
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the typed password. Hence, also an authentication scheme 
may be applied in which not only the authentication of a 
SIM card or the like is checked, but also of the user 
itself, since the user itself has to type the password. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be more readily understood 
10 with reference to the accompanying drawings in which: 

Fig. 1 shows a diagram illustrating a signaling flow 
between a SIP server, a SIP proxy and mobile node MS 
according to a preferred embodiment of the invention, 
15 wherein the authentication is verified in the SIP server, 

Fig. 2 shows a diagram illustrating a signaling flow 
between a SIP server, a SIP proxy and mobile node MS 
according to the preferred embodiment of the invention, 
20 wherein the authentication is verified in the SIP proxy, 

Fig. 3 shows a diagram illustrating a signaling flow 
between a SIP server, a SIP proxy and mobile node MS 
according to the preferred embodiment of the invention, 
25 wherein authentication is verified in an authentication 
center , 

Fig. 4 shows a diagram illustrating a signaling flow 
according to a modification of the preferred embodiment 
30 of the invention, and 

Fig- 5 shows a diagram illustrating a signaling flow 
according ro a further modification of the preferred 
embodiment of the invention. 

35 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

In the following, a preferred embodiment of the invention 
5 is described in mors detail with reference to the 
accompanying drawings . 

According to the present embodiment, a mechanism is 
introduced which allows an authentication of terminated 
10 SI? calls by requesting the terminated node to 

authenticate itself as a part of the call termination 
procedure . 



That is, during the call termination procedure, i.e., 
15 receiving a call invitation from another party and 

responding to this invitation, also an authentication is 
performed . 



Such an invitation and responding may be advantageously 
performed by using the SIP (Session Initiation Protocol) , 
however, it is noted that the present invention is not 
limited thereon. 

In particular, the invitation according to SIP is 
performed by sending two requests; A SIP INVITE request, 
by which the caller invites the callee to participate in 
a particular call or multimedia session or the like. The 
callee answers with a SIP response. In case he agrees to 
participate in the call, the callee sends a 200 OK 
response to the caller. The caller then sends a second 
SIP request, i.e., ACK request, in order to acknowledge 
the response of the callee- Otherwise, in case the caller 
is no longer interested in the call or session, he may 
send a BYE request to the callee in order to terminate 
~he session. 
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The requests, in particular the INVITE request, contain 
several information within fields- For example, a 
description of the session to which the callee is invited 
5 is included in the fields. 

According "co the present embodiment, an additional field, 
i.e., an additional parameter has to be included into the 
SIP INVITE request. Namely, the information needed for 

10 performing the authentication is included in the SIP 

INVITE request. In particular, the RAND number which is 
provided by an authentication entity (e.g., AuC or a SIP 
server which actually performs the authentication) has to 
be included in bhe SIP INIVXTE request- These additional 

15 authentication is referred to as authentication extension 
in the following . 

According to the present embodiment, the WWW-Authenticate 
Response-Header field which is already defined in SIP is 
20 used for such a field. 

In SIP as currently defined, the WWW-Authenticate 
response-header field has to be included in 401 
(Unauthorized) response messages. The field value 
25 consists of at least one challenge that indicates the 

authentication scheme (s) and parameters applicable to the 
Request-URI . 

Thus, no new field has to, be defined, but an already 
30 defined field (which, however, was used for another kind 
of request) may include the necessary information, namely 
the RAND, i.e., challenge, and information regarding the 
authentication scheme. 

35 After receiving such a SIP INVITE request, the mobile 
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node responses with a SIP response like, e.g., 200 OK or 
the like. Furthermore, the mobile node calculates the 
RESP_CALC value and includes this value into the SIP 
response . 

5 

Hence, also a new field has to be included into the SIP 
responses. Preferably, also here an already defined field 
may be adopted for such a field. According to the present 
embodiment, the Authorization Request Header field may be 
10 included into the SIP response. 

According to SIP as currently defined, the Authorization 

Request header field is included in case a user agent 
hQ wishes to authenticate itself with a server, usually (but 

"9 15 not necessarily) after receiving a 401 (Unauthorized) 

*Z response. The Authorization field value consists of 

,p credentials containing the authentication information of 

the user agent for the realm of the resource being 

requested. 

S3 20 

is „ i 

s y In the following, some of the possible SIP messages into 

Uj which the Authorization Request Header field has to be 

13 added according to the prosQnt. embodiment are described 

in short: 

25 

1) SIP INVITE: as mentioned above, the WWW-Authenticate 
Response-Header field (already defined in SIP) needs to 
be added - 

30 2) SIP 200 OK: the Authorization Request Header field 
(already defined in SIP) needs to be added. The 200 OK 
response is sent in case the SIP INVITE request has 
succeeded- The information returned with the response 
depends on the method used in the request, for example 
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INVITE: The callee has agreed to participate; the message 
body indicates the callee 's capabilities. 

3) 403 Forbidden: the Authorization Request Header 
5 field (already defined in SIP) needs to be added. This 
response is sent in case the server understood the 
request, but is refusing to fulfill it. Authorization 
will not help, and the request should not be repeated. 



10 4) 405 Not allowed: the Authorization Request Header 
field (already defined in SIP) needs to be added. This 
response is sent in case the method specified in the 
Request-Line is not allowed for the address identified by 
the Request-URI „ The response must include an Allow 

15 header field containing a list of valid methods for the 
indicated address. 

5) 408 Request Timeout: the Authorization Request 
Header field (already defined in SIP) needs to be added. 

20 This response is sent in case the called entity could not 
produce a response, e.g., a user location, within the 
time indicated in an Expires request-header field. 

6) 409 Conflict: the Authorization Request Header field 
25 (already defined in SIP) needs to be added. This response 

is sent in case the request could not be completed due to 
a conflict with the current state of the resource. This 
response is returned if the action parameter in a 
REGISTER request conflicts with existing registrations. 

30 

7) 410 Gone: the Authorization Request Header field 
(already defined in SIP) needs to be added. This response 
is sent in case the requested resource is no longer 
available at the called entity (i.e., in the present 
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embodiment, the mobile node MS) and no forwarding address 
is known. 

8) 415 Unsupported Media Type: the Authorization 
Request Header field (already defined in SIP) needs to be 
added, This response is sent in case the called entity is 
refusing to service the request because the message body 
of the request is in a format not supported by the 
requested resource for the requested method. 

9) 420 Bad Extension; the Authorization Request Header 
field (already defined in SIP) needs to be added. This 
response is sent in case the server did not understand 
the protocol extension specified in a Require header 
field. 

10) 480 Temporarily Unavailable: the Authorization 
Request Header field (already defined in SIP) needs to be 
added. This response is sent in case the callee's end 

20 system (i.e., the mobile node) was contacted successfully 
but the callee is currently unavailable (e.g., not logged 
in or logged in in such a manner as to preclude 
communication with the callee) . 

25 11) 482 Loop Detected: the Authorization Request Header 
field (already defined in SIP) needs to be added. This 
response is sent in case the server received a request 
with a via path containing itself. 

30 12) 484 Address Incomplete: the Authorization Request 
Header field (already defined in SIP) needs to be added. 
This response is sent in case the called entity received 
a request with a To address or Request-URI that was 
incomplete. 

35 
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13) 485 Ambiguous: the Aurhori zation Request Header 
field (already defined in SIP) needs to be added. This 
response is sent in case the callee address provided in 
the request was ambiguous. 

5 

14) 4S6 Busy Here: the Authorization Request Header 
field (already defined in SIP) needs to be added. This 
response is sent in case the called entity (i.e., the 
cailee's end system) was contacted successfully but the 

10 callee is currently not willing or able to take 
additional calls, 

15) 603 Decline; the Authorization Request Header field 
(already defined in SIP) needs to be added. This response 

15 is sent in case the called entity was successfully 

contacted but the user explicitly does not wish to or 
cannot participate, 

16) 606 Not Acceptable: the Authorization Request Header 
20 field (already defined in SIP) needs to be added. This 

response is sent in case the called entity was contacted 
successfully but some aspects of the session description 
such as the requested media, bandwidth, or addressing 
style were not acceptable* A 606 {Not Acceptable) 
25 response means that the user wishes to communicate, but 
cannot adequately support the session described. 

In the following an example is given as to how a 
challenge response authentication procedure is adopted to 
30 authenticate the mobile node: 

The above-described WWW-authenticate Response Header 
field contains : 

35 i. indication of challenge response algorithm 
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ii. a RAND parameter 

iii. a RESP parameter 

where RAND is a random parameter generated by an entity, 
5 here named AuC (Authentication Center), that is outside 
the scope of this invention. AuC also generates the RESP 
parameter, i.e., the scheduled result. 

When the mobile node (i.e., called entity) sends any of 
10 the responses 2-16 identified above, the above described 
Authorization Request Header field will contain the 
parameter CALC_RESP (of the same length of RESP) . 

In the following, the authentication procedure according 
to the present embodiment is described by referring to 
Fig. 1. 

In this example, a call is to be initiated between a 
caller (calling mobile node MS , as an example for an 
originating entity) and a callee (called MS, as an 
example for a subscriber entity) via a SIP server and a 
SIP proxy (as examples for a network control element) , It 
is noted that both SIP server and SIP proxy may be 
technically structured in the same way, however, their 
functions are different. The server serves the caller, 
while the proxy forwards signaling, 

1) The SIP server, receiving an incoming mobile 
terminated call for a mobile node from a calling party 
30 (step SI) , determines that the call needs to be 

authenticated (e.g. based on profiles or policies) (step 
S2) and retrieves (according to a mechanism outside the 
scope of the invention) necessary data for the 
authentication from,, an authentication center (step S3) - 
35 These authentication data include first data AuthDatal 
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which is to be forwarded to the called mobile node and 
second data AuthResp which is to be used by the SIP 
server. 



5 2) The SIP server forwards the SIP INVITE request 
(containing the authentication extensions with the 
authentication parameters) towards the mobile node (steps 
34 and S5) . According to the present embodiment, the SIP 
server determines according to network policies that it 
10 is the authentication verification point. Hence, it 

forwards the SIP INVITE request with the authentication 
extensions containing only AuthDatal and puts its URL in 
the VIA field. 



15 Any SIP server or proxy receiving an authentication 
extension with only AuthDatal will simply forward the 
message. In the signaling diagram according to Fig* 1, 
this is the case for the SIP proxy receiving the SIP 
INVITE request from the SIP server. That is, the SIP 

20 proxy forwards the SIP INVITE request to the mobile node 
unchanged . 

3) The mobile node (MS), receiving the SIP INVITE 
request containing the RAND parameter, executes the 
25 authentication algorithm taking AuthDatal as input and 
producing an output value AuthData2- 



4) When the mobile node answers to the SIP INVITE 
request with any of the messages identified in the above 

30 points 2-16, it returns the AuthData2 parameter. In the 
signaling diagram shown in Fig. 1, it is assumed that the 
user accepts the SIP INVITE request and that there are no 
further problems {due to which one of the above responses 
3 to 16 would be sent) . Thus, a 200 OK response is sent 

35 in step S6. 
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5) The response is forwarded transparently by the SIP 
proxies until it reaches the SIP server designated for 
the verification for the authentication. In the example 
5 of Fig. l f only one SIP proxy is concerned, and this SIP 
proxy forwards the 200 OK response including the 
parameter AuthDat:a2 of the mobile node to the SIP server 
in step 37. 

10 6) The SIP server verifies the parameter AuthData2 with 
the parameter AuthResp which was retrieved from the 
authentication center in step S3. 

After a successful verification of the authentication, 
the SIP server forwards the 200 OK response of the mobile 
node to the caller in step S9. In case of an unsuccessful 
authentication, the SIP server may send a corresponding 
failure message to the caller. Such a message may be a 
405 Not Allowed message including a parameter indicating 
to the caller that the authentication of the callee was 
unsuccessful . 

In case of a successful authentication, the caller may 
send an SIP ACK request after receiving the 200 OK 
25 response. That is, the session is established according 
to normal SIP. 

The above steps were described with respect to general 
authentication. In the following, the steps are shortly 
30 described in case a challenge response is employed. 

In this case, the parameter AuthDatal sent to the called 
mobile node in steps S4 and S5 is the parameter RAND. The 
mobile node calculates the parameter CALC__RESP, which is 
35 the parameter AuthData2 sent to the SIP server in steps 
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S6 and S7 . The parameter AuthResp retrieved from the 
authentication center in step S3 is the parameter RESP. 
Thus, in step 38 the verification is performed by 
comparing the value of RESP with the value of CALC_RESP. 
5 If both values are equal, the authentication is 
successful, otherwise it fails. 

As already mentioned above, the functions of the SIP 
proxies/servers included in the path between the caller 

10 and callse may be different. This is illustrated in the 
example of Fig. 2 showing a signaling flow between a 
caller and a callee via a SIP server and a SIP proxy, 
wherein in this example it is assumed that the SIP server 
is not the authentication verification point, but the SIP 

15 proxy. The SIP server may determine according to network 
policies that it is not the authentication verification 
point. In this case, it forwards the SIP INVITE request 
with the authentication extensions containing AuthDatal 
and AuthResp- 

20 

Any SIP server or proxy receiving authentication 
extension with both RAND and RESP decides whether to 
forward the INVITE message with only RAND or whether to 
forward the INVITE message with both RAND and RESP. 

25 

The first alternative (forwarding the INVITE message with 
only RAND) happens if the mobile node is directly 
reachable by the SIP server or proxy without passing 
through any other SIP server or proxy (this can be 
30 determined by screening the list of users who have 

registered to this SIP server/proxy) . Otherwise, the 
first alternative may happen based on network policies. 
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The second alternative (forwarding the INVITE message 
with both RAND and RESP) happens based on network 
policies . 

5 In the signaling flow of Fig. 2, same or similar steps as 
in Pig. 1 are denoted by same reference signs, such that 
a repeated description thereof is omitted. 

As mentioned above, in this example the SIP server 
10 determines based on the network policies that it is not 
the authentication verification point, but the SIP proxy. 
Hence, it forwards the INVITE request including AuthDatal 
and AuthResp to the SIP proxy 1 in step S4a. 

15 Based on the network policies and on receiving the INVITE 
request includingAuthDatal and AuthResp, the SIP proxy 
determines that ib is the authentication verification 
point. Hence, it extracts the AuthResp from the INVITE 
message and stores it. Thereafter, it forwards the INVITE 

20 request including only AuthDatal in step S5. In addition, 
the SIP proxy includes its address in the VIA field in 
order to indicate that it is the authentication 
verification point . 

25 In step S7a, the SIP proxy verifies AuthData2 with 

AuthResp, in the same way as it is performed by the SIP 
server in step SB of Fig. 1. 

In case of a positive result, the SIP 200 OK response is 
30 forwarded ro rhe caller in steps SS8a and S9 via the SIP 
server . 

Fig. 3 shows a signaling flow for a case in which neither 
a SIP proxy nor a SIP server performs the authentication, 
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but wherein the authentication is performed by an 
authentication center . 

In the signaling flow of Fig. 3, same or similar steps as 
5 in Fig- 1 are denoted by same reference signs, such that 
a repeated description thereof is omitted. 

As mentioned above, in this example both the SIP server 
and the SIP proxy determine based on the network policies 
10 that they are not the authentication verification point, 
but the authentication center* Hence, in step S3b only 
the AuthDatal to be sent to the called mobile node is 
retrieved. 

15 In step S3b, the SIP server performs an Authentication 
Data Request including AuthData2 from the called mobile 
note to the authentication center, which in turn verifies 
AuthData in step S8c. In step S8d, the authentication 
center sends an Authentication Data Response to the SIP 

20 server. In case of positive authentication, the SIP 

server forwards the SIP 200 OK response in step 39 to the 
calling party. Otherwise, the SIP server may send a 
failure message to the calling party/ as described above. 

25 Fig. 4 shows a modification of the preferred embodiment, 
according to which the callee may also perform a network 
authentication . 

When performing user authentication, the user may also 
30 want to authenticate the network to prevent network 

impersonation* A man in the middle may otherwise try to 
send requests to the valid user and re-use the 
authentication result to perform undesirable operations. 



35 



In Fig. 4, basically the same situation as shown in Fig. 
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2 is considered. That is, it is assumed that the SIP 
proxy performs the verification. However, also the other 
si-uarions as described above with connection to Fig. 1 
and 3 are possible. Same reference signs in Fig, 4 and 
5 Fig. 2 indicate same or basically same steps, and only 
those steps different from those of Fig. 2 are described 
in the following. 

Thus, after the SIP INVITE request including AuthDatal, 
10 the callee produces AuthData2 in response to the 

AuthDatal. In addition, the callee (i.e., the subscriber 
equipment) creates additional authentication data 
AuthData3, These authentication data are used for the 
network: authentication. 

15 

In step S10, the authentication result, AuthData2, and 
the additional authentication data AuthData3 are sent to 
the SIP proxy. Here, a suitable SIP message may be used, 
for example a 401 Unauthorized message. That is, a 200 OK 
20 message (as in case of Figs- 1 to 3) is not sent yet 
since the callee wants to perform a network 
authentication first . 

In step Sll the SIP proxy verifies AuthData2, and after a 
25 positive verification, the SIP proxy produces 

authentication data AuthData4 in response to the 
AuthData3, which are sent to the callee in step S12- The 
authentication data AuthData4 may be included in a 
suitable SIP message. In step S13 the callee verifies 
30 AutData4, and only in case the verification is 

successful, the callee sends the SIP 200 OK response in 
step S14. This SIP 200 OK response is forwarded to rhe 
caller in steps S15 and S16. 



35 As an example, when receiving the RAND (as described 
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above as an example for AuthDatal) , the callee computes 
the RES (as described above as an example for AuthData2) 
to get authenticated by the network. But in the same 
time, he may also generate a RANDU (as an example for 
5 AuthData3) to authenticate the network. The callee will 
therefore send both the RES and the RANDU to the network. 
The network will authenticate the user based on the RAND 
and RES as described above in the description of the 
first embodiment. 

10 

In addition, if user authentication is successful, the 
network computes network authentication data (as an 
example for AurhData4) based on RANDU and sends it back 
to the caller. 

15 

This is an example of possible network authentication 
required by the user when the network wants to 
authenticate him. 

20 It is noted that in the above-described example of Fig. 4 
it is assumed that the SIP proxy has the necessary 
information for determining the network authentication 
data AuthData4. However, in some cases the SIP proxy may 
not have this information and/or capabilities. In this 

25 cases, the SIP proxy may need to contact the SIP server 
or Authentication Center (AuC) to compute the network 
authentication data. That is, in Fig. 4, the SIP server 
may access, during step Sll, the SIP server and/or the 
authentication center . 

30 

Fig. 5 illustrates a further modification of the 
preferred embodiment according to which a multiple round 
trips authentication scheme is applied. In Fig. 5, same 
reference signs as in Fig. 1 denote the same steps, so 
35 that only different parts are described in the following* 
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According to rhis modification authentication scheme is 
used which requires many round trips between the user and 
the network. Basically, steps S3 to SS of Fig. 1 may be 
5 repeated for a predetermined number of times, wherein 

always different AuthDatal may be supplied to the callee. 

This is shown in Fig. 5 by the steps S23 to S38 which are 
enclosed in a dotted box. It is noted that in steps S24 
10 to S27 SIP INVITE and SIP 200 OK messages may be used as 
in steps S4 to S7 for conveying the corresponding 
authentication data, however, also other suitable SIP 
messages or other kind of messages may be used. 

15 In every repetition of the loop consisting of the steps 
S23 to S28, a new set of authentication data AuthDatal 
and AuthResp is retrieved from the Authentication Center 
in step S23, That is, in each loop, a values for 
AuthDatal and AuthResp are set. 

20 

After finally the authentication of the subscriber has 
been confirmed, the SIP 200 OK response is forwarded to 
the caller in step S9. 

25 According to the above example, also the Authentication 
Center is involved to process the authentication data 
(i.e., after a successful result of each part- 
authentication, a new authentication data set is 
supplied) . However, alternatively also the SIP server may 

30 be supplied already in step S3 with all necessary 

information (i.e., all different values for AuthDatal and 
AuthResp in each loop) . 

As a further alternative, the process according to Fig- 5 
35 may also be applied to that- of Figs. 1 and 3- Moreover, 
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it may also be combined with that of Fig. 4, That is, 
after the final confirmation of the authentication, also 
a network authentication may be performed. 

5 The above description and accompanying drawings only 

illustrate the present invention by way of example. Thus, 
the embodiment may vary within the scope of the attached 
claims. For example, the above embodiment and the 
modifications thereof may be arbitrarily combined. 

10 

In particular, the authentication procedure described 
above is not limited on the challenge-response algorithm, 
but other different existing authentication schemes can 
be applied in which authentication data are sent to a 

15 called node and authentication response data are produced 
by the called node. Some of the existing authentication 
schemes may require many round trips (and not only one as 
described above), e.g. the user may also generate a 
challenge and try to authenticate the network in the same 

20 time, he provides the user authentication data. 

An example for another authentication scheme, UMTS AKA 
(Authentication and key agreement as defined in 3GPP TS 
33.102 can be executed. Here, in addition to the RAND as 
25 described above, another parameter AUTN is provided for 
the user. By this parameter, the user is able to perform 
an authentication of the network. 

Moreover,, also a password based authentication scheme 
30 could be used. In this case, the SIP INVITE message as 
described above, some text requesting the user to type 
his password can be included. That is, the authentication 
data AuthDatal as shown in the figures comprises this 
text. After the user has typed his password, this 
35 password may be included in the authentication data 
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AuthData2 as described above. The password may not be 
conveyed as plain text, but may also be ciphered such 
that no one in between can read the password. 
Moreover, there are several locations (network entities) 
5 where the authentication data can be added/removed to 

support the authentication. The SIP server, SIP proxy and 
authentication center described above are only examples. 

Furthermore, it is noted that in the embodiment described 
10 above the VoIP (Voice over IP, i.e., Internet Protocol) 

was only mentioned as an example. The invention is by no 

way limited thereon and can be applied to any kind of 

network system in which an authentication is performed. 

For example , the invention can also be applied to GSM and 
15 UMTS network systems. For example, it may be applied in 

IETF (Internet Engineering Task Force) and/or 3GPP (Third 

Generation Partnership Project) . 

Moreover, also the SIP protocol is only taken as an 
20 example for a control protocol. Any control protocol 
which issues invitation messages and corresponding 
responses including fields into which the information 
necessary for performing an authentication may be 
included can be used. 

25 

Moreover, it is noted that the invention is not limited 
on mobile nodes as callers and/or callee. Instead, any 
type of communication device, either fixed or mobile, may 
be applied. 



30 



